软件架构设计体系
「提出问题」普通程序员，亦或是中高级开发者到架构师往往是一个较难逾越的问题。「阐述架构目的」首先架构的目的，在于解决解决企业的业务、管理(效率)、技术问题。技术角度主要是系统复杂性问题。「分析难点和要点」之所以难以成为架构师，主要原因在于缺乏对业务知识、管理知识的融合运用，以及对架构知识的系统性积累和实践。以系统架构师、AI 架构师、数据架构师等为例，想要成为一名合格的架构师，关键在于对架构知识进行系统的积累与实践，不仅要深入理解架构设计，掌握架构设计方法论，还要熟悉相关的业务和管理知识。「写作目的」基于此，本篇文章将围绕这些要点，系统地构建架构知识体系，旨在帮助读者应对未来工作中的岗位职责要求，和助力解决面试问题，成为优秀的架构师。
本章也作为平台工具部分的核心，其他章节为本章的架构设计服务(大型系统设计)
架构设计本质上是对系统效率(efficiency)、透明度(transpareny)和复杂度(complexity)的系统性治理。
1 | ▲ 透明度(可观测性、流程/关系) |
顶层的视角主要从三个维度展开，做架构的设计。其中效率(Efficiency)的具体目标有系统性能（吞吐量、延迟）、成本效率（资源利用、运维成本）、 开发交付效率（CI/CD、部署效率）等；透明度(Transparency)的具体目标有可观测性（监控、日志、追踪）、数据/模块流向清晰（架构解耦、调用链清晰）、依赖关系 & 状态可见性；复杂度(Complexity) 的具体目标包括系统耦合度（模块之间关系）、 扩展性/演进性（支持变更、灰度发布）、可维护性 & 学习曲线等。
一、架构设计目的
「重要性」有效的企业架构(EA)画出美好蓝图，对企业的生存和成功具有决定性的作用，是企业通过IT获得竞争优势的不可缺少的手段。其目的主要聚焦于解决企业业务、管理(效率等)和技术问题。
「分述」业务角度看架构将复杂的业务需求转化为系统功能模块，并能适应变化(大到企业数字化转型，小到系统的演进变化)；
在管理层面，企业架构明确各部分关系，促进团队高效协作，同时降低开发、运维等成本，全面提升企业运营效率；
技术层面，企业架构致力于解决技术复杂度问题，包括系统实现和优化(提升维护性、扩展性、性能；模块合理拆分管理)、保障安全(稳定性、系统安全)等。
从技术角度看，架构设计的核心目的是在应对业务复杂度的同时，合理选型与设计，解决系统在高可用性、扩展性、高并发、可演进性等方面的挑战，从而降低整体系统复杂度。
系统烟囱式建设；系统边界模糊扯皮现象频发；
系统重复建设，标准不统一；系统之间无法集成，阻碍创新；
后续过程中系统难以演进和维护，问题频发等。
[架构的理解]架构的规划与治理本质上也是一种管理行为。管理的核心，是管理者通过协调资源与活动、制定决策、建立秩序等方式，提升组织的效率与效益，以实现整体目标。同时，管理也承担着塑造积极组织文化的职责，促使组织内部各要素协同运作，实现最优绩效。与之相辅的是项目管理，其本质是在时间、预算、质量等约束条件下，运用专业的知识、技能、工具与方法，对项目从启动到收尾的全过程进行计划、组织、协调、控制与监督。项目管理旨在整合与优化各类资源配置，确保项目目标的实现，并满足各相关方的合理期望。
1.1 满足业务需求
抛开业务谈架构都是不切实际的，真正好的架构，永远是围绕业务演进做减法、做抽象、做护航的。
因此我们首先要满足业务需求，并且结合业务场景做合适的架构演进。而不是“过度设计”或“脱离实际”。
比如:(1)刚创业的小体量的业务场景，上来就搞DDD、微服务、分布式事务 是有点过度架构了，合理的是单体为主，接口清晰，快速迭代；
(2)一个只做 ToB 运营后台的服务，引入复杂缓存和异地多活，其实数据写一致性优先，本地高可用就够了；
(3)一个增长迅猛的电商系统，硬编码业务逻辑，不留扩展点，其实抽象订单引擎、支付网关，支持灵活组合的架构更合理。
因此，也可以说架构不是设计出来的，而是随着业务发展“生长”出来的。真正实用的架构，是一门结合业务洞察 + 技术手段 + 团队能力的“平衡艺术”。
1.2 复杂度问题
系统耦合度（模块之间关系）、 扩展性/演进性（支持变更、灰度发布）、可维护性 & 学习曲线
1.3 透明度问题
可观测性（监控、日志、追踪）、数据/模块流向清晰（架构解耦、调用链清晰）、依赖关系 & 状态可见性
1.4 效率问题
系统性能（吞吐量、延迟）、成本效率（资源利用、运维成本）、 开发交付效率（CI/CD、部署效率）等
二、架构师知识体系
基于以上架构的目的和重要性，我们如何才能设计出优秀的架构，来赋能企业和组织以及技术系统，带来更多价值。我认为有3点内容：
深入理解业务流程、拓展技术视野、方法论的总结和运用(包括技术、管理等)。「待完善和纠正」
2.1 架构的认识
阐述 企业架构、技术架构、业务架构、软件架构、数据架构之间的关系和层级。
我们通常互联网企业或者制造业中涉及的包括 系统架构、技术架构、软件架构。例如：各类SaaS云服务、大数据平台、班组建设管理信息、人口宏观管理信息，都是软件系统。
从业务领域划分，这类属于软件开发。以及运营服务平台 都是软件开发类。
还包括技术平台，或者PaaS层，例如用友的…,希望软件的HopeSource平台。
系统架构师的范围更广泛，还需考虑系统集成等复杂问题。
「企业架构师」
「系统架构师」
「技术架构」
「软件架构」
「数据架构师」
2.1 企业架构框架理论
作为目前应用最广泛的企业架构框架理论-TOGAF，提供了完善且不断优化迭代的知识体系以支持EA高效落地。
2.1.1 TOGAF
简单来说，TOGAF的架构模型定义了：1.为什么干(战略目标、业务动机)，2.干什么(业务功能,需要哪些能力)，3.谁来干(组织结构、业务角色)，4.怎么干(业务流程、业务规则)，5.用到的数据(业务数据有哪些)，6.用到的应用(有哪些应用系统），7.用到的技术(技术设施有哪些)
TOGAF 在全球范围内得到了广泛的应用和认可，许多大型企业都采用 TOGAF 来指导其企业架构的建设和管理，是企业架构领域的重要标准和最佳实践之一。
2.1.2 框架内容
其框架内容包括：架构开发方法（ADM）、架构内容框架、架构能力框架、参考模型。
①.开发方法
TOGAF 的核心，是一个迭代的、基于流程的方法，用于开发和维护企业架构。它包括九个阶段，从架构愿景的确定，到需求管理、架构设计、实施规划、迁移规划，再到架构变更管理等，每个阶段都有明确的目标、输入、输出和关键活动。
②.内容框架
定义了企业架构中所包含的各种元素和工件。提供了一种标准化的方式来描述和组织企业架构的各个方面，使得不同的利益相关者能够更好地理解和沟通。
企业架构之4A架构：业务架构、数据架构、应用架构和技术架构是企业架构的四个主要架构，它们在关注的方面和功能上有所不同，但它们是相互管理和相互支持的，共同构成了企业的总体架构。
③.能力框架
关注于企业如何建立和发展自身的架构能力，包括架构团队的组织和管理、架构师的技能和素质要求、架构流程的改进和优化等方面。
2.1.3 核心价值
提供标准化方法、促进业务与IT融合、支持技术选型和集成、增强沟通和协作
2.1.4 应用场景
企业战略规划：帮助企业高层管理者从整体上规划企业的发展方向，确定业务和 IT 战略，确保企业的长期发展目标与架构规划相一致。
IT 架构设计与转型：在企业进行 IT 系统升级、改造或数字化转型时，TOGAF 可以提供指导，帮助企业设计出合理的 IT 架构，实现系统的集成和协同，提高 IT 资源的利用效率。
项目管理和实施：在具体的项目实施过程中，TOGAF 可以帮助项目团队更好地理解项目的目标和范围，明确项目与整体企业架构的关系，确保项目的交付符合企业的整体架构要求。
2.2 架构的分类
以上的TOGAF框架理论包含的4A架构内容，为其核心内容，是 TOGAF 方法论在企业架构实践中的具体对象和内容。
关于架构的重要性：这里在提一下，架构是系统实现的蓝图、是沟通协作的桥梁、是产品质量的基础
2.2.1 4A架构
4A架构包括：业务架构、应用架构、数据架构、技术架构。 其中技术支撑业务、业务支撑战略。
业务架构：是一种对组织如何利用其基本能力实现其战略意图和目标的正式描述。
技术架构：将产品需求转变为技术实现的过程，关注点：识别技术需求、进行技术选型、非功能性需求设计。
2.3 架构设计原则
2.3.1 SOLID
2.3 领导力
这张图系统的介绍了架构师的能力模型。 目前认为最主要的包括 领导力(项目管理等)、架构设计方法论 这两点。
围绕这两点需要的下层技能，逐步补充和完善技能。以成为合格的架构师。
三、架构实践
四、架构认识
总结一些不是重点的内容
4.1 架构师角色
根据职责边界和关注点的差异可以分不同角色的架构师，这其中底层的方法论有一定的通用之处，也有一些不同和侧重。
但都致力于通过 合理的架构设计来支持业务的发展和技术的有效应用。
这些不同的分类也不是完全独立的，有一定的关联性。 比如AI架构，可以视为 特点领域的技术架构，同时也与软件架构密切相关。
我们这里的架构设计 以软件架构、技术架构为主，总结系统的方法和必备技能，构建并完善架构师能力模型。
| 分类 | 说明 |
|---|---|
| 企业架构师 | 关注整个企业的IT战略和架构，确保各个业务部门的系统能够协调运作，以实现企业的业务目标 |
| 解决方案架构师 | 针对特定的业务问题或需求，设计全面的技术解决方案，包括软件、硬件、网络等方面的整合 |
| 软件架构师 | 专注于软件系统的架构设计，包括系统结构、模块划分、接口设计、技术选型等，以确保软件的可扩展性、可维护性和性能 |
| 数据架构师 | 负责设计和管理组织的数据结构，包括数据库、数据仓库、数据治理、数据集成等，以确保数据准确性、完整性和可用性 |
| 技术架构师 | 侧重于技术平台和基础设施的架构设计，例如云计算平台、服务器架构、网络架构等，为应用系统提供可靠的技术支撑 |
| 安全架构师 | 关注系统的安全架构设计，制定安全策略和措施，防范各类安全威胁，保障系统和数据的安全 |
| 系统架构师 | 关注系统整体架构、宏观角度规划、系统功能分解、子系统和模块、交互关系、接口规范、部署方式，综合考虑性能、可靠性等 |
4.2 技术图谱
技术图谱参考:https://gitee.com/qfork/architect-all.下面的各个子目录及文章将围绕这个模型展开系统梳理各个技能细节。
4.3 其他
①.领域知识
对特定领域深入了解 是至关重要的。 要知道它是什么，将是什么，可能是什么，以及为什么。
客户经常找到软件架构师，要求向他们展示行业领导者正在做什么以及如何做。领域知识还可以帮助软件架构师说一种商业通用的语言，这反过来帮助他们成为连接管理和开发团队桥梁。
风控、搜索、其他
人际较往能力：展示自己的技能需要的，如倾听、口头和书面沟通、推进、冲突管理、演示、谈判和说服。
专业技术：需要学习软件工程的所有领域，包括软件设计、编码、质量保证、DevOps、性能分析、软件安全、项目管理、软件支持等等。
这些技能对于创建满足软件架构“能力”的解决方案至关重要。当与开发团队中的专家交流时，软件架构师能够更好地理解相关信息，因为他们已经具备了这些领域的实践经验。
作为开发团队成员，可以胜任各个领域的日常工作，包括后端、前端和 DevOps。
项目管理：
从以下几个方面展开，系统学习架构设计. todo
- 基础知识：计算机网络、操作系统、数据库、算法与数据结构等.
- 常用架构模式：分层架构、微服务架构、事件驱动架构等(理解这些模式的优劣势，以及在不同场景下的适用性).
- 设计原则：高内聚低耦合、单一职责原则、开闭原则等(有助于设计出易于维护和扩展的系统架构).
- 实践经验总结：学习业界的实践经验和成功案例，阅读相关的书籍、博客和论文，了解其他人在系统设计方面的思路和经验.
- 持续学习和改进：订阅相关的技术期刊、邮件列表或社交媒体，保持对新技术和趋势的关注，不断学习和改进自己的架构设计能力.
- 使用设计工具：总结好用的工具(设计工具和建模语言)，帮助更好地理解和表达系统架构设计.
- 实践.